Product Construction Service

The ABSTRACT FACTORY pattern is a solution often used for isolating clients from the construction of concrete objects. Normally a new concrete factory class is developed for each concrete product family. Therefore new specific construction code has to be written each time a new product family needs to be supported. This approach influences software productivity negatively as it only covers the reuse of design ideas. In order to minimize the effort involved in supporting a new product family, the reuse of code should also be achieved. A configurable factory as described in the implementation section of the ABSTRACT FACTORY pattern would be an appropriate solution. This would result in less implementation effort and thus in an increased software productivity. The PRODUCT CONSTRUCTION SERVICE pattern describes how to realize a configurable factory. Also known as Configurable Factory Generic Factory Classification Object Creational Example Consider an application that has to deal with two problem domains: workflow and organization. Within the workflow domain, abstractions like Process, ProcessDef and WfHandler can be found. A ProcessDef object describes a process and a Process object represents an actual workflow process that can be instantiated on a workflow system via a workflow handler object (WfHandler). A WfHandler is a SINGLETON. That means that there can be only one WfHandler per workflow system. Imagine that the application should be able to support different workflow systems. At first, the Livelink workflow system could be used. In the future, it will be possible to migrate to a workflow system by another vendor, i.e. Staffware, or to support several simultaneously. In order to enable clients to work with different concrete workflow systems without knowing them directly, unified interfaces need to be introduced. This allows clients to communicate with concrete objects through their abstract interface. In the workflow example the vendor specific classes are derived from Process, ProcessDef and WfHandler. This is illustrated in Figure 1. The classes that belong for example to the Livelink product family are prefixed with “LL” and the ones belonging to the Staffware product family with “SW”. 1 s. [LiveLink2000] 2 s. [Staffware2000] Process <> ProcessDef <> W fHandler <> LLProcess SWProcess LLWfHandler SWWfHandler LLProcessDef SWProcessDef Figure 1: Workflow Domain Classes The next step would normally be the usage of the typical ABSTRACT FACTORY pattern by modeling an abstract factory that declares the needed interface for the construction of workflow products. AbstractWorkflowFactoryWorkflowFactory createProcess() : Process createProcessDef() : ProcessDef createWfHandler() : WfHandler <> Figure 2: Abstract Workflow Factory After that two concrete factories would be derived from AbstractWorkflowFactory: one that handles the Livelink and one that handles the Staffware product family. This is illustrated below. AbstractWork flowFactoryWork flowFactory createProcess() : Process createProcessDef() : ProcessDef createWfHandler() : WfHandler <>